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DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 10/25/07. 

As indicated in Applicant's response, claims 1, 3-8, 11, 13-14, 21, 26, 34 have been 
amended, claims 10, 20, 22-23, 27-28, 31-33 canceled. Claims 1-9, 1 1-19, 21, 24-26, 29-30, 34- 
36 are pending in the office action. 

Claim Objections 

2. The numbering of claims is not in accordance with 37 CFR 1 .126 which requires the 
original numbering of the claims to be preserved throughout the prosecution. When claims are 
canceled, the remaining claims must not be renumbered. When new claims are presented, they 
must be numbered consecutively beginning with the number next following the highest 
numbered claims previously presented (whether entered or not). 

Misnumbered 'claim 22' recited within claim 24 (line 1) should now be corrected 
because claim 22 has been canceled; likewise, misnumbered claim 27 recited within claim 29 
must be corrected because claim 27 has been canceled. Claim 24 is further objected to because 
of the following informalities: the reciting of 'generating the application program threads 
comprises' appears to be a contextually unfit phrase because there is no sufficient prior basis 
(slightest reference to) for a thread-generating statement in the base claim (e.g. claim 21). 
Appropriate correction is required 

3. Claim 2 is objected to because of the following informality: The claim has been marked 
as "Currently Amended" whereas there is no amendment made to the text of the claim. This is 
non-compliancy with respect to CFR § 1.121c according to which proper parenthesized 
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identifiers should accompany appropriate text markings whenever a change applies; and will be 
treated herein as a mere objection to possibly expedite prosecution. 

4. Claims 1 1, 35 are objected to because of the following informalities: 'bonding 
instructions' - in association with 'boundary instructions'. The 'bonding instruction' (cl. 11, 
line 10; cl. 35, line 5) is strongly suggestive of a typographical error or misuse of language, 
because bonding is clearly different from boundary. Lack of antecedent basis can be applied as a 
35 use 1 12 type of rejection in case no correction is made. 

5. Claims 35-36 are objected to for the following improper syntax: 'wherein the compiler to 
cause building...' , 'wherein the compiler to cause hoisting' (line 1); i.e. lacking connecting verb 
between 'wherein ... compiler' and 'to cause'. Suggested proper grammatical construct for 
those phrase would be: 'wherein the compiler is operable to cause' 

Appropriate correction is required. 

Claim Rejections - 35 USC § 112 

6. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

7. Claim 24-25 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. Claim 24 is rejected under 35 U.S.C. 1 12, second paragraph, as being incomplete 
for omitting essential steps, such omission amounting to a gap between the steps. See MPEP 

§ 2172.01 . The omitted steps are: there must be at least some identification of critical sections 
between the partitioning (re claim 21) and the generating (claim 24) of threads prior to the 
executing of threads - via synchronization based on the identification of critical sections. 
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Specifically, claim 24 recites 'processing identified critical sections to reduce an amount 
of code contained within critical sections ... program loops' in the context of 'generating the 
application program threads'. One of ordinary skill in the art would find obscure how processing 
identified critical sections is done, because there is no sufficient basis as to how identification of 
critical sections has been achieved, nor is there any 'generating' step being done prior to, during, 
or subsequent to identifying of critical sections (refer to 'Claim Objection' for improper 
referencing to canceled claim 22). The claim only introduces a partitioning step (re claim 2 1 ) 
according to a thread count context, a thread executing step, and a synchronizing step in regard 
access of identified critical sections. It is unclear how processing to 'reduce code within critical 
sections' is a same context with claim 21 when no generating and no identification of critical 
sections have been recited in relation to 'executing' or even the 'synchronizing' step. The 
Specifications describes establishing a CFG and based on some identification of sections, 
implement boundaries therefor, and applying code motion techniques to reorder the section of 
the graph according to such identification and based on which, implementing thread 
synchronization (Specifications: Figure 5, 9, 1 1-13), In claim 24, the recited 'generating ... 
application program threads' is not commensurate with the graph-based reordering as disclosed, 
nor is this 'generating' remotely related to updating of a CFG, for it is even more out of context 
with claim 21, when the 'partitioning' step therein ( 'partitioning a sequential application ... 
according to a thread count') operates on a thread count (Question: is thread count the result of 
code reducing - see claim 24 — or prior to code reducing?). Lacking essential teachings (e.g. 
identification of critical sections based on partitioning of a CFG flow analysis, using sections 
boundaries, reordering using some technique prior to execution), one of ordinary skill in the art 
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would not be able to construe a 'generating step' for 'processing' identified sections; and this 
'processing ... reduce ... amount of code ' step will be treated with broad interpretation (at best) 
without a full patentable weight. Claim 25 is also rejected for dependent of an indefinite claim, 

8. Claims 1 1, 35 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. Claims 1 1, 35 are objected to because of the following informalities: 'bonding 
instructions' - in association with 'boundary instructions'. The 'bonding instruction' (cl. 11, 
line 10; cl. 35, line 5) is strongly suggestive of an error in use of language, because bonding is 
clearly different from boundary. There is no sufficient prior teaching in the claim, particularly in 
relation to the 'boundary instructions', to convey the metes and bounds of what bonding is all 
about. The above lack of defmiteness has not been resolved via any enabling form from 
scanning the Disclosure, and will be treated as a lack of antecedent basis, or at best as a typo 
error. 

Claim Rejections - 35 USC § 103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

10. Claims 1-2, 1 M2, 21, 24, 26, 29, 34-35 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Sohi et al, "Multiscalar Processors", 1995, ACM 0-89791-698; pp. 414-425 
(hereinafter Sohi) 

As per claim 1, Sohi discloses a method comprising: 
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building a control flow graph (CFG) for a loop body of a sequential application program 
to form a CFG loop (e.g. CFG ... entire loop - sec 2.1, L col. pg. 415); 

updating nodes of the CFG loop to enclose identified sections of the sequential 
application program within pairs of boundary instructions {t.g. partitioned ... tasks - R col. pg 
414; partitioned ... boundaries of a task ... instruction at exiting edges - R col. pg. 417; 
iteration ... sequential instruction stream ... Head and tail ... current tasks ... values are bound 
to storage ... registers and memory - pg. 415, bottom R to pg. 416, top L col.); and 

forming a plurality of application program thread partitions (e.g. search ... linked list 
parallel execution - bottom R col. pg. 416 to top 417 L col; Fig. 4 - Note: updating and resolving 
values via traversing a CFG for parallel re-allocating of correctly resolved task each in its 
runtime own context reads on generating of thread partitions - see: each ofM^hich fetches and 
executes the instructions in its task-s^Q sec 6, pg. 425; threads ... multiscalar processor - pg. 
422, R col. top) from a modified CFG loop, 

wherein nodes (e.g. bottom L pg. 417 to R col. pg. 417; see updates and forwards - pg. 
418, L col.) of the CFG loop are modified (e.g. confirm ... correct execution ... correct path ... 
CFG is resolved incorrect must be squashed ... correct data recovered . . . retiring the task ... 
updating the head pointer- pg. 416, R col. top & middle) to reduce an amount of instructions 
between corresponding pairs of boundary instructions to form a modified CFG loop (e.g. pg. 
41 6, R col. top & middle - Note: retiring task with readjusted path based on register value at 
head and tail recordings reads on reducing code between boundaries - see sec 3, pg. 419); and 
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synchronizing execution of the identified sections of concurrently executing application 
program threads to ensure that the identified sections are executed in a sequential thread order 
(e.g. sec 3.1.1 pg. 419). 

But Sohi does not explicitly disclose that the identified sections are critical sections and, 
based on which to partition and synchronize execution of those identified critical sections. 
However, Sohi teaches synchronizing in view of memory accesses to ensure no conflicts and this 
is strongly suggestive on avoiding contention for variable access (e.g. offending accesses - top L 
col. pg. 420) among instructions being traversed during Sohi's CFG partitioning; hence discloses 
addressing memory accesses in terms that they are critical as in being potentially problematic to 
the resource dependency related to the parallel execution of tasks. To that effect it can be 
reasonable to say that Sohi addresses critical sections; hence, this 'critical section' limitation 
would have been if not disclosed, then obvious. For one skill in the art at the time the invention 
was made it would have been obvious to implement the boundary instructions by Sohi so that 
regions being identified as register-related accesses (see L col. pg. 416; sec 2.2, pg 417, L col) 
are critical memory access regions on the CFG in light of the dependency of potential successors 
with respect to a predecessor in the CFG (e.g. sec 3.1.1, pg. 419-420), because this would 
enforce a more proper boundary instructions to address such potential contention between 
successor and predecessor task or thread in the sections being analyzed in Sohi static setup (see 
Fig. 2, pg 415; task descriptor - pg. 417-418) 

As per claim 2, Sohi (in view of the rationale in claim 1) discloses wherein updating the 
CFG loop comprises: 
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selecting an identified critical section of the sequential application program (Fig. 2, pg 
415; task descriptor - pg. 417-418); and inserting boundary instructions at a top node and a 
bottom node of the CFG (e.g. Head, Tail - Fig. 1, pg. 415); 

repeating the selecting, inserting and inserting for each identified critical section of the 
sequential application program (e.g. R col. pg. 417; pg. 415, bottom R to pg. 416, top L col. ). 

As for the inserting recited as: inserting an await instruction within a top node of the 
CFG loop; inserting an advance instruction within a bottom node of the CFG loop, this is 
deemed disclosed by Sohi, as follows. 

Sohi discloses a multiscalar model of execution uses a CFG to inspect instruction 
dependency per tasks per processor for re-ordering based on path inspection (see pg. 414, R 
column; col, 415, R col; re-ordered - sec 4.1) and one such task being inspected is coordinated 
with bit or mask implemented as an instruction at the beginning of a CFG region just so said 
instruction would indicate a wait within a subsequent forward step dependent on whether 
resources are properly allocated to be released for the awaiting task to continue or advance (see 
must wait ...to release in order to continue - pg. 417, R col; pg 418, L col). Hence, Sohi also 
discloses a wait at the top of a critical section and an advance when resources are correct for 
resuming a waiting task. 

As per claim 11, Sohi disclose an article of manufacture including a machine readable 
medium having stored thereon instructions which may be used to program a system to perform a 
method, comprising: 

building a control flow graph (CFG) for a loop body of a sequential application program 
to form a CFG loop; 
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updating nodes of the CFG loop to enclose identified sections of the sequential 
application program within pairs of boundary instructions; and 

modifying forming a plurality of application program thread partitions from a modified 
CFG loop where nodes of the CFG loop are modified to reduce an amount of instructions 
between corresponding pairs of bonding instructions to form a modified CFG loop; and 

synchronizing execution of the identified sections of concurrently executing application 
program threads to ensure that the identified critical sections are executed in a sequential thread 
order. 

All of which limitations have been addressed in claim 1 . 

But Sohi does not explicitly disclose that the identified sections are critical sections and, 
based on which to partition and synchronize execution of those identified critical sections. This 
limitation has been addressed in claim 1 . 

As per claim 12, refer to claim 2. 

As per claim 21, Sohi discloses a method comprising: 

partitioning a sequential application program into a plurality of application program 
threads according to a thread count (e.g. search ... linked list parallel execution - bottom R col. 
pg. 416 to top 417 L col; Fig. 4 - partitioned node on CFG leading to reordering for task 
execution in parallel reads on generating of thread partitions according to thread count - see: 
threads ... multiscalar processor - pg. 422, R col. top) of a multi-threaded architecture; and 

concurrently executing the plurality of application program threads (see: each of which 
fetches and executes the instructions in its task- see sec 6, pg. 425; threads ... multiscalar 
processor - pg. 422, R col. top) within a respective thread of a multi-threaded architecture; and 
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synchronizing access to identified sections of the sequential application program among 
the plurality of application program threads to execute the identified critical sections of the 
application program threads loop in sequential thread order (sec 3.1.1 pg. 419). 

But Sohi does not explicitly disclose that the identified sections being synchronized are 
critical sections; however, this limitation has been deemed an obvious limitation as set forth in 
claim 1. 

As per claim 24, Sohi discloses wherein generating the application program threads 
comprises: processing identified critical sections to reduce an amount of code (e.g. confirm ... 
correct execution ... correct path ... CFG is resolved incorrect must be squashed ... correct data 
recovered retiring the task ... updating the head pointer- pg. 416, R col. top & middle - 
Node: eliminate task for which resources are not proper reads on reducing code between 
boundary of critical sections; sec 3.1 pg. 419 ) contained within critical sections of thread 
program loops. 

As per claim 26, Sohi discloses an article of manufacture including a machine readable 
medium having stored thereon instructions which may be used to program a system to perform a 
method, comprising: 

partitioning a sequential application program into a plurality of application program 
threads according to identified sections {e.g. partitioned ... tasks - R col. pg 414; partitioned ... 
boundaries of a task ... instruction at ... exiting edges — R col. pg. 417; iteration ... sequential 
instruction stream ... Head and tail ... current tasks ... values are bound to storage ... registers 
and memory - pg. 415, bottom R to pg. 416, top L col ) within the sequential application 
program; and 
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concurrently executing the plurality of application program threads within a respective 
thread of a multi-threaded architecture; and 

synchronizing access to the identified sections among the plurality of concurrently 
executing application program threads to ensure that the identified sections 
are executed in a sequential thread order; 

all of which having been addressed in claim 24. 

But Sohi does not explicitly disclose that the identified sections being synchronized are 
critical sections; however, this limitation has been deemed an obvious limitation as set forth in 
claim 1 . 

As per claim 29, refer to claim 24 

As per claim 34, Sohi discloses a system comprising: a processor; a memory controller 
coupled to the processor; and a DDR SRAM memory coupled to the processor, the memory 
including a compiler is operable to cause 

partitioning of a sequential application program into a plurality of application program 
threads according to identified sections within the sequential application program to enable 

concurrent execution of the plurality of application program threads within a respective 
thread of a multi-threaded architecture and 

to synchronize access to the identified sections among the plurality of concurrently 
executing application program threads to ensure that the identified sections are executed in a 
sequential thread order; 

all of which having been addressed in claim 21. 
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But Sohi does not explicitly disclose that the identified sections being synchronized are 
critical sections; however, this limitation has been deemed an obvious limitation as set forth in 
claim 1. 

As per claim 35, Sohi discloses wherein the compiler to cause building a control flow 
graph (CFG) for a loop body of a sequential application program to form a CFG loop to cause an 
update of nodes of the CFG loop to enclose identified critical sections of the sequential 
application program within pairs of boundary instructions (e.g. partitioned ... tasks - R col. pg 
414; partitioned ... boundaries of a task ... instruction at ... exiting edges - R col. pg. 417; 
iteration ... sequential instruction stream ... Head and tail ... current tasks ... values are bound 
to storage ... registers and memory -pg. 415, bottom R to pg. 416, top L col) and 

to cause modification of nodes of the CFG loop to reduce an amount of instructions (e.g. 
confirm ... correct execution ... correct path ... CFG is resolved incorrect must be squashed ... 
correct data recovered retiring the task ... updating the head pointer- pg. 416, R col. top & 
middle - Node: eliminate task for which resources are not proper reads on reducing code 
between boundary of critical sections; sec 3.1 pg. 419) between corresponding pairs of bonding 
instructions to form a modified CFG loop. 

1 1 . Claims 3-9, 13-19, 25, 30, 36 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Sohi et al, "Multiscalar Processors", 1995, ACM 0-89791-698; pp. 414-425; in view of 
Vijaykumar T.N., "Compiling for the Multiscalar Architecture", University of Wisconsin, 1998, 
pp. 1-191 (hereinafter Vijayk). 

As per claim 3, Sohi disclose await and advance instructions as in 
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reordering identified motion candidate instructions within the nodes of the CFG loop with 
fixed await instructions and fixed advance instructions (see pg, 414, R column; col. 415, R col; 
re-ordered - sec 4. 1 ; see must wait ... to release in order to continue - pg. 41 7, R col; pg 41 8, L 
col); 

but does not disclose wherein forming (the thread application partitions) comprises: 
hoisting detected hoist instructions from identified motion candidate instructions within the 
nodes of the CFG loop using code motions with fixed await boundary instructions into 
corresponding predecessor basic blocks; and sinking detected sink instructions from identified 
motion candidate instructions within the nodes of the CFG loop using code motion with fixed 
advance instructions into corresponding successor basic blocks. 

The code motion based on judicious analysis of program resources based on CFG and 
program resources information collected by a compiler for scheduling a multiscalar ILP 
execution, as by Sohi, is also disclosed in Vijayk, and according to which, Vijayk discloses 
successor task or predecessor task susceptible to be rescheduled or stalled based on register data 
validation or prediction implemented by wait instructions or (resources) forward annotation (Fig. 
3-6, pg. 61; Fig. 4-8, pg. 100; sec 4.4.5-4.4.6); and that code motion can applied to candidature 
blocks based on a wait so to be hoisted to a higher layer of CFG critical portion (or basic blocks) 
without disrupting the structure of the tree basic block dependency (see Fig, 4-9, 4-10, pg. 101- 
102; Fig. 4-13, pg. 109); and well as sinking of instruction to send them deeper into another 
successor CFG sub-tree (pg. 102-103; Fig. 4-10; sec 4.5.5 ,pg. 108-110; Fig 4-15, 4-16 pg. 1 13) 
to reduce redundant stall cycles. It would have been obvious for one skill in the art at the time 
the invention was made to implement to wait and resources forward boundary instructions by 



Application/Control Number: 10/714,198 Page 14 

Art Unit: 2193 

Sohi to that Sohi's partitioning of the modified node information based on registers also include 
code motion as to reduce unused code cycles and improve overall code size by hoisting 
instructions to where resources can be resolved earlier in the predecessor portion or forwarded 
into a successor sub-tree as explained in the multiscalar's ILP compiler by Vijayk. One would 
be motivated to do so because this enable the amount of unused cycles (e.g. in Sohi's 
predecessor or successor subtrees) be optimized and therey reduce the code between two 
bounded critical subtree via hoisting and sinking as evidenced by Vijayk in the scheduling of 
task, resources validation and look-ahead control for loop restructuring ( see pg. 60-1 17) 

As per claim 4, Sohi discloses initializing a CFG for code restructuring based on register 
data validation and tasks reducing or squashing using await for resource resolution; that is, Sohi 
discloses queue of task order for setting boundary instructions ( see queue - R col. bottom pg. 
415) and prediction with advance knowledge to reduce stalling of cycles ( see Sohi: minimizing 
cycles lost , pg. A2\\ predictor ... advance knowledge - sec 4.2 pg. 422) 

but does not specifically disclose wherein hoisting detected hoist instructions with fixed 
await instructions comprises: 'identifying every instruction within a basic block the CFG loop, 
excluding await instructions, as a motion candidate instructions; building an inverse graph of the 
CFG loop; initializing a hoist queue with the basic blocks from the CFG loop, the basic blocks 
ordered according to a topological order indicated by the inverse graph; hoisting motion 
candidate instructions of the basic blocks into corresponding predecessor basic blocks until hoist 
instructions are no longer detected from the identified motion candidate instructions; and 
hoisting detected hoist instructions from motion candidate instructions within a source basic 
block of the CFG loop according to a dependence graph of the sequential application program'. 
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The providing of candidate motion instructions is disclosed in Vijayk using traversal of a 
forward tree and reverse tree (Fig. 3-13, pg. 79; upward ... reverse topological order - pg. 102); 
and using algorithm to investigate candidate instruction (set as list of task - see Fig. 3-1 1, pg 75) 
based on the tree initialization and basic block resource analysis (e.g. register stalls Fig. 4-5, 4-6, 
pg. 95-96) and dependency of predecessor and successor in order to implement hoisting and 
sinking (refer to claim 3), i.e. until hoist instructions are no longer detected from the identified 
motion candidate instructions. It would have been obvious for one skill in the art at the time the 
invention was made to implement the CFG resources dependency by Sohi so that it is initialized 
in form of basic blocks with dependency of resources as by Vijayk, as well as task allocation and 
resolution of dependency based on upward and then reverse traversal, and then predicting the 
instructions exclusively within the boundary instructions as set forth in claim 1 , to promote code 
motion as set forth in claim 3 above using the teaching by Vijayk; because this would enable 
Sohi's multiscalar ILP compiler to further achieve code reduction (as set forth in claim 3) and bi- 
directional establishing of adjusted dependency while searching of candidate instructions to be 
moved (sinking or hoisting - see Vijayk: pg. 101-103) 

As per claim 5, Sohi does not disclose wherein hoisting detected hoist instructions from 
the motion candidate instructions of the basic blocks comprises: 

de-queuing a basic block from the hoist queue as a current block; 

computing hoist instructions from the motion candidate instructions based on a 
dependence graph of the sequential application program; 
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hoisting the computed hoist instructions into a corresponding basic block; and 
enqueuing the current block's predecessors from the CFG loop into the hoist queue when a 
change is detected. 

Sohi discloses queue of task order for setting boundary instructions ( see queue - R col. 
bottom pg. 415) and prediction with advance knowledge to reduce stalling ( see Sohi: minimizing 
cycles lost , pg. 421 ; predictor ... advance knowledge - sec 4.2 pg. 422) in order to determine 
how task being initialized in a CFG (see Fig. 2, pg. 415) can be removed to reduce cycle stalling. 
Based on the code motion technique by Vijayk (refer to claim 3) using the same resource 
dependency validation and sequencer/predictor as in Sohi and also in view of the dequeuing (i.e. 
enqueueing at first prior to dequeueing) of task as by Vijayk (see Control Flow heuristics, 
dequeue - Figure 3-10, pg. 74), the de-queuing of a candidate basic block for code motion — 
identified as not disclosed in Sohi— would have been obvious in view of the rationale ~ using the 
teaching by Vijayk — to address traversal of an initialized tree of CFG until hoist instructions are 
no longer detected from the identified motion candidate instructions (i.e. heuristics for 
initializing task or candidate instruction as ordered list and dequeuing one by one), in claim 4. 

As per claim 6, Sohi does not explicitly disclose identifying motion candidate 
instructions within the basic blocks of the CFG loop through dataflow analysis with fixed 
advance instructions; initializing a sink queue with the basic blocks ordered based on a 
topological order in the CFG loop; sinking detected sink instructions among the basic blocks into 
corresponding successor basic block until sinking instructions are no longer detected from the 
identified motion candidate instructions; and reordering detected motion candidates within basic 
blocks that contain advance instructions according to the dependence graph. 
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But code motion using a initialized candidate task or basic blocks using a predictor and 
dependency of register resource allocation based on such candidate instruction or basic block for 
sinking or hoisting has been addressed in dequeueing/enqueueing limitations as set forth in claim 
5 above in light of the rationale of claim 4, 

As per claim 7, Sohi does not explicitly disclose wherein sinking detected sink 
instructions among the basis blocks comprises: de-queue a basic block from the sink queue as a 
current block; computing sink instructions from motion candidate instructions based on a 
dependence graph of the sequential application program; sinking computed sink instructions into 
a corresponding successor basic block; and en-queuing a current block's successors in the CFG 
loop into the sink queue if a change is detected. But the dequeing and enqueing limitation has 
been addressed as obvious for both hoisting and sinking as set forth in claim 5 in view of the 
hoist/sink candidate or listed instructions being hoisted or sunk {until ... instructions are no 
longer detected) of claim 4. 

As per claim 8, Sohi discloses reordering the identified motion candidates instructions 
within basic blocks (e.g. part of a basic block, a basic block - sec 2.2, top L col. pg. 4 1 5) that 
contain await instructions based on a dependence graph of the sequential application program 
(refer to claim 1); but does not disclose initializing a hoist queue with the basic blocks ordered 
based on a topological order in the CFG loop; identifying motion candidate instructions within 
the basic blocks of the CFG loop through dataflow analysis with fixed advance instructions and 
fixed await instructions; hoisting detected hoist instructions among the basic blocks into 
corresponding predecessor basic blocks until hoist instructions are no longer detected from the 
identified motion candidate instructions. 
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But the initializing of basic block being bounded by some fixed AWAIT or ADVANCE 
instructions for analysis of dataflow so to hoist or sink (until hoist candidate instructions are not 
longer detected) has been addressed in claim 4. 

As per claim 9, Sohi does not explicitly disclose wherein motion candidate instructions 
hoisted out of an outmost await instruction are no longer treated as motion candidates; and 
wherein motion candidate instructions out of an outmost advance instruction are no longer 
treated as motion candidates. But the candidate instructions being hoisted from a initialized 
candidate list as by Vijayk (until hoist candidate instructions are not longer detected) amount to 
the subject matter as set forth in claim 4; and would have been obvious using the rationale of 
claims 4 and 5. 

As per claims 13-19, refer to claims 3-9, respectively. 

As per claim 25, Sohi does not disclose wherein code motion is used to reduce the 
amount of code contained within critical sections of the thread program loops. But the hoist and 
sink code motion has been addressed in claim 3 above, using Vijayk. 

As per claim 30, refer to claim 25. 

As per claim 36, refer to claim 3. 

Response to Arguments 
12. Applicant's arguments filed 10/25/07 have been fully considered but they are not moot in 
light of the new grounds of rejection, which are necessitated by the Amendments. 

In whole, the claims will stand rejected as set forth in the Office Action. 

Conclusion 
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13. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 . 1 36(a). 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The 
examiner can normally be reached on 8AM-4:30PN4/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Meng-Ai An can be reached on (571)272-3756. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609, 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent Application Information 
Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR 
or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more 
information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the 
Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




Tuan A Vu 
Patent Examiner, 
Art Unit 2 193 
December 16,2007 



